Amiga Developer CD 2.1/Amiga Developer CD v2.1.iso/Reference/Amiga_Mail_Vol2/Archives/Plain/ma93.lha/MenuVerify/MenuVerify.txt

Text File | 1993-05-19 | 13.2 KB | 270 lines

(c) Copyright 1993 Commodore-Amiga, Inc.   All rights reserved.
The information contained herein is subject to change without notice,
and is provided "as is" without warranty of any kind, either expressed
or implied.  The entire risk as to the use of this information is
assumed by the user.

Menu Verify Handling


by John Orr and Peter Cherna


Menu verify has been a part of Intuition for a long time, so it may
seem a bit odd to see an Amiga Mail article on the subject.
Unfortunately, the ``Intuition Menus'' chapter of the Amiga ROM Kernel
Reference Manual: Libraries is a bit unclear on the subject.  It does
not sufficiently cover why an application would need to use this
feature and how an application should handle it.


Menu Verify

When the user tries to pull down the active window's menu, Intuition
offers applications a chance to prepare for the menu operation.
Intuition delays displaying any menus until the application has
finished its preparations for the menu operation.  This feature is
known as menu verify.

Menu verification works using the IDCMP mechanism.  For an Intuition
screen, when the user triggers Intuition into drawing the menu,
Intuition sends an IDCMP_MENUVERIFY message to every window on that
screen that asked to hear about menu verify events.  Intuition will not
display the menus until it gets back all the IDCMP_MENUVERIFY messages.

If the active window uses menu verification, Intuition gives that
window the option to cancel the menu operation.  This allows the
application to selectively use the menu button to activate the menu or
to perform some other function.

Beginning with V36, Intuition introduced a time out on menu verify
operations.  If the active window's application takes too long to
respond to the IDCMP_MENUVERIFY message, Intuition will cancel the menu
operation.  This feature helps avoid some deadlocks that can occur
while Intuition is waiting on the active window.  This feature applies
only to the active window; Intuition will wait indefinitely for the
IDCMP_MENUVERIFY message from an inactive window.


Reasons to Use Menu Verify

The primary purpose of the menu verify feature is to arbitrate access
to screen resources.  There are really only two screen resources that
an application might need to use directly, the palette and the bitmap.

Some applications need as many pens as possible, so they change the
color values of the pens that Intuition uses to render the menus.  This
can present a problem if the application happens to alter the menu pen
colors so that the menu's foreground color is difficult (if not
impossible) to see against the background color.  The menu items will
be unreadable to the user.

To prevent this problem, the application has to restore the original
pen colors when the user pulls down the menu.  The application can do
this using menu verify.  When the user hits the menu button, Intuition
sends the application a menu verify message.  When the application
receives this message, it restores the menu colors and then returns the
IDCMP_MENUVERIFY message so Intuition can properly render the menus.
When the menu operation is over, Intuition will send a ``conclusion''
IDCMP message.  The ``conclusion'' message is covered later in this
article.

Another reason to use menu verify is to arbitrate rendering access to
an Intuition Screen's bitmap.  While Intuition is displaying the menus,
the application must not render directly to the screen's bitmap because
the application could draw over the menus.  The application must wait
until the menu operation is over to resume rendering.

This raises some important questions.  Why render into a screen's
bitmap (Screen-> RastPort.BitMap)?  Shouldn't I render into a window
instead?

The quick answer is: ``render into a window's rastport instead of
rendering directly into a screen's bitmap''.  Rendering to a window's
rastport offers several advantages over rendering directly to the
screen's bitmap.  The window offers the application efficient clipping,
making the application simpler because it doesn't need to worry about
rendering into rectangular bounds.  The window also supports a layered
display, so the application can ignore the consequences of arbitrating
access to the screen's bitmap.

There are some cases where, arguably, it might be advantageous for an
application to render directly into a screen's bitmap.  Rendering into
a screen's bitmap versus rendering to a window's rastport offers a
slight improvement in performance.  Part of this improvement is due to
the lack of clipping on a screen's bitmap, which the window provides,
so the performance improvement is questionable if you still need to
perform clipping.

One case where an application has to render into a screen's bitmap is
when graphics functions that operate below the layers level.  For
example blitter objects (BOBs) operate below the layers level.  If the
application is operating below the layers level, it can't render to a
windowed display.


Reasons Not to Use Menu Verify

One feature of Intuition menus is that the user can toggle a menu item
between a selected ``checked'' state and an unselected ``unchecked''
state.  Intuition keeps track of the state, so the application only has
to read the state from the MenuItem structure.  In some cases, the
state of the menu item can be affected by something besides the user
performing menu operations, so the application has to explicitly change
the state of the menu item.

Some applications use the menu verify feature as a mechanism for
updating the state of the menu items.  When such an application
receives the IDCMP_MENUVERIFY message, it updates the checked flag of
the menu items and then returns the menu verify message.  Some
applications also use this method to manage the enabled and disabled
state of a menu item.

Although this method works, it should not be necessary to interrupt the
menu event.  Almost all applications should be able to keep their menu
states current using ResetMenuStrip().  It is also possible to use
SetMenuStrip(), but since ResetMenuStrip() is considerably faster than
SetMenuStrip(), ResetMenuStrip() is better.  See the Autodoc for
ResetMenuStrip() for more details.

Some people may think one potential use for menu verify is to assign an
alternative meaning to the right mouse button.  For example, when the
pointer is not within the title bar of a screen, some paint packages
use the right mouse button to paint using the background color.  Using
menu verify, it is possible for a application to intercept the menu
verify event, checking to see if the pointer is within the title bar.
If it isn't, the application cancels the menu event.  After cancelling
the menu event, Intuition will send a right button down event, which
the application can interpret.

This mechanism may work, but it is not very efficient.  There is a
better way to do this using WFLG_RMBTRAP.  This flag is from the Flags
field in the Window structure.  When set, this flag disables menu
operations for the window.  When the user hits the menu button,
Intuition sends the window IDCMP_MOUSEBUTTONS events instead of menu
events.

To use WFLG_RMBTRAP as an alternative to menu verify, the application
tracks mouse movement using IDCMP_MOUSEMOVE.  While the pointer is
outside of the screen's title bar, the application makes sure the
WFLG_RMBTRAP flag is set.   If the user hits the right mouse button
while WFLG_RMBTRAP is set, Intuition sends the application a mouse
button event.  While the pointer is inside the screen's title bar, the
application makes sure the WFLG_RMBTRAP flag is clear.  If the user
hits the right mouse button while WFLG_RMBTRAP is clear, Intuition
generates a normal menu event for the window.

WFLG_RMBTRAP is an exception to most fields in Intuition structures
because it is legal for an application to directly modify this flag.
Note that this change must take place as an atomic operation so that
Exec cannot perform a task switch in the middle of the change.  If you
are unsure your compiler will do this, use a Forbid()/Permit() pair to
prevent a task switch.

There are cases where an application is too busy to handle any menu
event so it needs to prevent menu operations for a while.  This is
another case where menu verify is inappropriate.  A better way to block
menus is to remove the menu with the Intuition function
ClearMenuStrip() and restore it later with ResetMenuStrip().  Another
potentially useful way to block menu operations is using a requester.


Will I Ever Need to Cancel a Menu Operation?

When the active window receives an IDCMP_MENUVERIFY message, it has the
option of cancelling the menu operation.  Although this feature may
have some possible uses, for the moment there is no recommended use for
it.


Handling Menu Verify Events

Typically, an application uses menu verify because the application
needs to know when the menus are down.  This goes for the menus of any
window on the screen, not just the application's window.  When the
application receives its IDCMP_MENUVERIFY message, it performs some
minor processing (restoring menu pen colors, for example) and records
the fact that the display is in a ``menu processing'' state (i.e.
Intuition is going to display the menus).  The application then returns
the menu verify message so Intuition can continue with the menu
operation.  The application cannot utilize the screen's resources until
the menu processing state is over.

There are two types of events that can end the menu processing state.
A cancellation or a menu pick can terminate the menu processing state.

There are several events that can cancel a menu operation.  Some
possibilities include Intuition timing out waiting for an outstanding
IDCMP_MENUVERIFY, the active window cancelling the menu operation, and
Intuition failing to allocate enough resources to display the menus.
The ``Intuition Menus'' chapter of the Amiga ROM Kernel Manual:
Libraries attempts to interpret these causes based on the IDCMP
messages that arrive after the application returns the IDCMP_MENUVERIFY
message.

The book should not have mentioned how to interpret the cause of a menu
cancellation.  The reasoning for the cancellation is not really
relevant.  Trying to interpret the cause of a menu cancellation is a
bad idea (especially if you interpret based on the information in the
book; it's wrong).  The only important fact is that the ``menu
processing'' state has terminated and the application can resume normal
operations.

Any of the following message combinations signify the cancellation of
the ``menu processing'' state:

  o IDCMP_MOUSEBUTTONS (IntuiMessage.Code is equal to MENUUP) only
  o IDCMP_MENUPICK (IntuiMessage.Code is equal to MENUNULL) only
  o IDCMP_MOUSEBUTTONS (IntuiMessage.Code is equal to MENUUP) then
      IDCMP_MENUPICK (IntuiMessage.Code is equal to MENUNULL)
  o IDCMP_MENUPICK (IntuiMessage.Code is equal to MENUNULL) then
      IDCMP_MOUSEBUTTONS (IntuiMessage.Code is equal to MENUUP)

Since the active window can cancel menu operations, the application may
need to determine if its window is the active window.  The application
can do this by examining the IntuiMessage.Code field of the menu verify
message.  If that field is equal to MENUWAITING (defined in
<intuition/intuition.h>) the window is not active.  However, if that
field is equal to MENUHOT (defined in <intuition/intuition.h>) the
window is active and can cancel the menu operation by changing the Code
field of the menu verify message to MENUCANCEL (also defined in
<intuition/intuition.h>).  If the application cancels the menu
operation, Intuition will send the active window an IDCMP_MOUSEBUTTONS
event about the right mouse button.

The following are possible cases signifying that the ``menu
processing'' state is over because the user successfully pulled down
and released the menu (there was no cancellation):

  o IDCMP_MENUPICK (IntuiMessage.Code is equal to the menu code)
  o (spurious) IDCMP_MOUSEBUTTONS (IntuiMessage.Code is equal to MENUUP)
      then IDCMP_MENUPICK (IntuiMessage.Code is equal to the menu code)

Note that the menu code could be MENUNULL if no item was selected.
IDCMP_MENUHELP events have the same meaning as the IDCMP_MENUPICK
messages when it comes to terminating the ``menu processing'' state.

There are rare cases in 3.0 and prior, where Intuition does not send
the application an IDCMP message after the user picks a menu item.  The
result is the application does not know that the ``menu processing''
state is over.  The only notable case is when the user types a menu
keyboard shortcut, and Intuition times out waiting for the application
to respond to the menu verify message.

V40 should fix the lack of a terminating event in those rare cases, as
well as eliminate the spurious IDCMP_MOUSEBUTTONS event that can occur
for successful menu picks.


About Double Menu Requesters

Intuition has a feature that allows an application to put up a special
type of requester when the user double clicks the right mouse button.
This requester is known as a Double Menu Requester.  Unfortunately, the
double menu requester is considered to be inconsistant with the Amiga's
user interface, so using them in any capacity is strongly discouraged.
Using them in conjunction with menu verify is even more strongly
discouraged because they significantly complicate processing menu
verify events.  For this reason, never use double menu requester and
menu verify together!